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A critical step towards certifying safety-critical systems is to check their conformance to hard real¬ 
time requirements. A promising way to achieve this is by building the systems from pre-verified 
components and verifying their correctness in a compositional manner. We previously reported a 
formal approach to verifying function blocks (FBs) using tabular expressions and the PVS proof as¬ 
sistant. By applying our approach to the IEC 61131-3 standard of Programmable Logic Controllers 
(PLCs), we constructed a repository of precise specification and reusable (proven) theorems of fea¬ 
sibility and correctness for FBs. However, we previously did not apply our approach to verify FBs 
against timing requirements, since IEC 61131-3 does not define composite FBs built from timers. 
In this paper, based on our experience in the nuclear domain, we conduct two realistic case studies, 
consisting of the software requirements and the proposed FB implementations for two subsystems 
of an industrial control system. The implementations are built from IEC 61131-3 FBs, including the 
on-delay timer. We find issues during the verification process and suggest solutions. 


1 Introduction 

Many industrial safety-critical software control systems are based upon Programmable Logic Controllers 
(PLCs). Function blocks (FBs) are reusable components for implementing the behaviour of PLCs in a 
hierarchical way. In one of its supplements, the aviation standard DO-178C [1] advocates the use of 
formal methods to construct, develop, and reason about mathematical models of system behaviours. 
Applying the principles of DO-178C to PLC-based systems, we may obtain high-quality PLCs by: 1) 
pre-verifying standard FBs using formal methods; 2) building systems from pre-verified components; 
and 3) verifying their correctness in a compositional manner. 

We recently reported a formal methodology IT01 for specifying requirements for FBs, and for verify¬ 
ing the correctness of their implementations expressed in, e.g., function block diagrams (FBDs). In our 
approach, we use tabular expressions (a.k.a. function tables) H21 for specification and the PVS proof 
assistant [9] for formal verification. Tabular expressions arc a way to document system requirements 
as black-box, input-output relations that has proven to be practical and effective in industry [14]. PVS 
provides an integrated environment with mechanized support for writing specifications using tabular ex¬ 
pressions and (higher-order) predicates, and for (interactively) proving that implementations satisfy the 
tabular requirements using sequent-style deductions. We successfully applied our approach to the FB 
library of IEC 61131-3 |6, Annex F], an industrial standard for PLCs, resulting in a repository of: 1) pre¬ 
cise specifications of input-output requirements; and 2) reusable theorems of feasibility and correctness 
for the FB library. 

A critical step towards certifying safety-critical systems is to check their conformance to hard real¬ 
time requirements. An implementable timing requirement must specify tolerances to account for various 
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factors — e.g., sampling rates, computation time, and latency — that will delay the software controller’s 
response to its operating environment. A common type of functional timing requirements specifies that 
a monitored condition C must sustain over a time duration, say timeout, with tolerances — 8L and +8R, 
before being detected by the controller. Such sustained timing requirements may be formalized using an 
infix Held_For operator [15]. For example, we write 

( ( signal > setpoint) Held-For (300, —50, +50) ) =» ( cjvar = trip ) (1) 

to specify that a sensor signal going out of its safety range should cause a “trip” if it sustains for longer 
than 350 ms, and should not if it lasts for less than 250 ms (to filter out the effect of a noisy signal). 

The requirement specified in Eq. 1 is non-deterministic since it allows any implementation that trips 
when signal > setpoint sustains between [250/n.v, 350ms]. As we will see in our two case studies, such 
a simple requirement can be used as part of specifying more complex real-time behaviour. To resolve 
such non-determinism, at the requirements level we adopt a deterministic operator Held-For J [4, p. 86], 
which becomes true at the first sampling point after the monitored condition has been enabled for d— 8L 
time units. For example, by substituting the expression (( signal > setpoint) Held_ForJ (300 — 50)) into 
Eq. 1, we specify that the triggering condition sustaining for longer than 250 ms should cause a “trip”. 
Similarly, at the implementation level we adopt the Timer J operator [4, p. 98] for counting the elapsed 
time of some monitored condition. The relationship between these two operators, at levels of require¬ 
ments and implementation, is proved as a theorem TimerGeneral J [4, p. 99]: (C Held-For J ( timeout — 
8L )) is equivalent to (Timer J (C) > timeout — 8L). See also Sec. 2. 

We previously did not apply our approach H01 to verify FBs against this type of more complex timing 
requirements because IEC 61131-3 only includes simple timer blocks (i.e, on-delay, off-delay, and pulse 
timers), but not any more complex FBs built from those timers. Furthermore, our requirements model 
for IEC 61131-3 timers H01 describes idealized behaviour: as the monitored condition becomes enabled, 
the timer instantaneously responds (i.e., starts counting the duration of enablement), not considering 
sampling, computational delays, and timing tolerances. 

Based on our experience on the Darlington Nuclear Shutdown Systems Trip Computer Software Re¬ 
design Project 1141 . and motivated by anticipated FB based projects, we address the above issues by 
conducting realistic case studies. Each case study consists of the software requirements and FBD imple¬ 
mentation for a subsystem of an industrial control system. Implementations are built from IEC 61131-3 
FBs, including the on-delay timer to implement more complex real-time behaviour. 

Fig. 1 summarizes our verification process and contributions. To incorporate the notion of tolerances, 
we reuse the timing operators Held-ForJ (to formalize requirements) and Timer J (to formalize imple¬ 
mentations) from [4]. The verification goal is that the proposed FBD implementations, included in the 
Software Design Description (SDD), are: (a) consistent, or feasible, meaning that an output can always 
be produced on valid inputs; and (b) correct with respect to the timing requirements specified using 
Held_ForJ, included in the Software Requirements Specification (SRS). This work builds on our previ¬ 
ous results of verifying IEC 61131-3 FBs 1101 that provide a sound semantic foundation for formalizing 
and verifying PEC programs expressed using FBDs. 

There are four contributions of this paper. First, to incorporate tolerances, we use the Timer J oper¬ 
ator to re-formalize all three IEC 61131-3 timer (Sec. 3). Second, for the representative subsystems we 
study (one with a feedback loop presented in Sec. 4 and the other in Sec. 5), we use the re-formalized 
IEC 61131 timers for their proposed FBD implementations, and prove that they are feasible and sat¬ 
isfy the intended timing requirements in SRS. Third, we find issues of initialization failure (Sec. 4) and 
missing implementation assumptions (Sec. 5), and suggest possible solutions. Fourth, we identify pat- 
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Figure 1: Framework for verification of FB based systems timing requirements 


terns of proof commands (Sec. 6) that are amenable to strategies (or proof scripts) that will facilitate the 
automated verification of the feasibility and correctness of other subsystems. 

Resources. Sources of the case studies (verified using PVS 6.0) are available at http://www.cas. 
monaster.ca/~lawford/papers/ESSS2015. Background theories (e.g., Held_ForJ , TimerJ, etc.) 
and complete details of case studies covered in this paper are included in an extended report rill . 


2 Preliminaries 

We review the use of tabular expressions, the relevant PVS theories of timing operators at levels of 
requirements and implementation, and the formal verification approach 1101 that is adapted in our two 
case studies (Sec. 4 _ and Sec. 5). 

2.1 Tabular Expressions Tabular expressions (a.k.a. function tables) 1121 are an effective approach 
for describing conditionals and relations, thus ideal for documenting many system requirements. They 
are arguably easier to comprehend and to maintain than conventional mathematical expressions. Tabular 
expressions have well-defined formal semantics (e. g., [7]). For our puipose of capturing the input-output 
requirements of timing function blocks, the tabular structure in Fig. 2 below suffices: rows in the first 
column denote input conditions, and rows in the second column denote the corresponding output results. 
The input column may be sub-divided to specify sub-conditions. When the output column denotes a state 
variable, we may write NC to abbreviate the case of “no change” on its value. 

In documenting input-output behaviours using horizontal condition tables (HCTs), we need to reason 
about their completeness and disjointness. Suppose there is no sub-condition, completeness ensures that 
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Figure 2: Semantics of Horizontal Condition Table (HCT) 


at least one row is applicable to every input, i. e., (Ci V C 2 V • • • V C n =True). Disjointness ensures that 
rows do not overlap, e. g., (/ j => —'(C/ AC/)). Similar constraints apply to the sub-conditions, if any. 

Choice of Theorem Prover. We chose the PVS theorem prover to formalize the input-output require¬ 
ments of function blocks primarily because it supports the syntax and semantics of tables. In particular, 
for each table that is syntactically valid, PVS automatically generates its associated healthiness condi¬ 
tions of completeness and disjointness as type correctness conditions (TCCs). Furthermore, we have 
expertise built from past experience in applying PVS to check requirements and designs in the nuclear 
domain [8] that gave us confidence in using the toolset. For modelling real-time behaviour, we reused 
parts of the PVS theories from [fg 4] (see Sec. 2.3 to 2.5). 

For presentation, we show PVS listings using ASCII characters in frame boxes, whereas in the main 
text, we typeset names of predicates, types, theorems, etc., in the math form. 

2.2 Modelling Time in the Physical Domain As PLCs are widely used in real-time systems, the 
modelling of time is critical. For our purpose of verification, we approximate the continuous time in 
the physical domain as a type tick, defined as a discrete series of equally-distributed clock ticks, with 
an arbitrarily small positive time interval 8 between two consecutive clock ticks: tick = {t n : R>o | 8 E 
M>o A On : N • t n = n x 5)}. We also define notJnit, a subtype of tick that excludes to- We define 
operators to manipulate values at the tick level: init(t : tick) = (t = 0), pre(t : notJnit) = (t — 8), next(t : 
tick) = (f+ 5), and rank(t : tick) = g . We often apply induction to prove properties that should hold 
over time^j 

time_induction: THEOREM 
FORALL (P: pred [tick]): 

(FORALL (t: tick): init(t) => P(t)) 

& (FORALL (t: not_init): P(pre(t)) => P(t)) => (FORALL (t: tick): P(t)) 

where pred[tick\ is a PVS shorthand for “predicates on tick” (i.e., functions mapping tick to Boolean). 

2.3 Modelling Samples in the Software Domain We use a variable Sample : N -» M> 0 to denote 
the series of samples over time, such that the time of each sample (i.e., Sample(n), 11 E N) maps to a 
valid clock tick. As shown in Fig. 3, realistically, the clock tick frequency ^ in the physical domain 
should be significantly larger than the sampling frequency in the software domain. We bound sample 
intervals between Tmin and Tmax, determined by considering the shortest time after which events must 
be detected. 

As rates of clock ticks and sampling are distinct, a monitored signal Pf that rapidly changes between 
two consecutive samples (called a “spike”) can cause inconsistent results produced in the two domains. 

*pred[tick] is synonymous to the function type [tick -> bool] 
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Figure 3: Clock Ticks in Physical Domain vs. Samples in Software Domain [4, p81] 


To rule out such scenarios, we define a predicate subtype FilteredTickPred 2 that only allows monitored 
conditions which remain unchanged between consecutive samples: 

FilteredTickPred?(P: pred[tick]): bool = 

( FORALL t®: P(tQ) /= P(next(t®)) => 

(FORALL (t: tick): 

t® < t AND t <= t® + Tmax => P(next(t®)) = P(t)) ) 

AND ( FORALL (t: tick): 

t <= Tmax => P(t) = P(®) ) 

FilteredTickPred: TYPE+ = (FilteredTickPred?) 

Pf: VAR FilteredTickPred 


2.4 Operators for Specifying Timing Requirements As discussed in Sec. 1, we define the infix 
operator: 

Held JFor : (tick —B) x (tick —> R>o) x (tick —> R>o) x (tick —> M>o) —>• (tick —> bool ) 

to specify a common functional timing requirement, e.g., P Held For (d. 8 L. 8 R), that a monitored 
boolean condition P should sustain over a positive time duration d, with non-negative left tolerance 5L 
and right tolerance 8 R. More precisely, 

P Held_For (d. 8 L , 8 R) (t now ) = ( 3tj : t now -tj>d • (Vt;: tj < U < t mm •P(h)) ) 

where d G [d(t now ) — 8 L(t now ),d(t now ) + 8 L(t, ww )]. In our model of time, inputs and outputs are repre¬ 
sented as functions mapping ticks to values. For example, the left tolerance may change from 8 L(t\) to 
8 L(t 2 )- However, as discussed in Sec. 1, the behaviour of Held_For is nondeterministic when P has held 
TRUE for a period that is bounded by [d — 8 L,d + SR]. 

To resolve the non-determinism in Held_For, we define two refinement operators: HeULFor_S and 
HeldJ'orJ. Both operators are deterministic by fixing the duration d in the above definition of Held For 
as d(t now ) — 8 L(t now ). We will only see HeldJForJ in the case studies, but it is defined in terms of 
Held-ForJS. HekLForS is a partial function on tick that produces values only at points of sampling (i.e., 
it is undefined on ticks in-between samples). 

Held_For_S(P, duration, Sample)(ne): bool = 

EXISTS (n® : nat): 

Sample(ne) - Sample(n®) >= duration 
AND FORALL (n: nat): n® <= n AND n <= ne => P(Sample(n)) 


2 An example of using the subtype FilteredTickPred to constrain input signals can be found in the verification story of the 
Pushbutton subsystem (Sec. 5). 
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On the other hand. Held-For lis a totalized version of Held_For_S\ its value at time t, where Sample(n) < 
t < Scimple(n + 1), is equivalent to that produced at time Sample(n) (i.e., the closest left sample calculated 
by Left Sample). 

Held_For_I(P, duration, Sample)(t): bool = 

Held_For_S(P, duration, Sample)(Left_Sample(Sample, t)) 

2.5 Implementing the HeldTFor J Timing Operator We use Timer J (defined in terms of TimerS) 
to implement the Held-For J timing operator. Timer J agrees on outputs from TimerS at sample points 
and keep the same value at any clock tick until the next sample point (this is analogous to how Held-For J 
is related to Held_ForS). 

Timer_I(P, Sample, TimeOut)(t): tick = 

Timer_S(P, Sample, TimeOut)(Left_Sample(Sample, t)) 

where Timer S\A_, p. 97] counts, starting from the closest left sample to the clock tick in question, for 
how long the monitored condition P has been enabled, and stops counting when TimeOut is reached. 
The output type of TimerS is tick, calculated from how many samples P has been held across. As 
mentioned in Sec. 1, the theorem TimerGeneral J is proved |4, p. 99] to ensure that Timer J is a proper 
implementation for Held_ForJ. 

2.6 A Formal Approach to Specifying and Verifying Function Blocks Our reported ap¬ 
proach 1101 fits into the timing model as described above. For each FB, its input-output requirements 
and FBD implementation are formalized in PVS as two (higher-order) predicates, parameterized by input 
and output lists. Each input or output is represented as a timed sequence (or trajectory) mapping clock 
ticks to values (e.g., [tick —> real]). Without loss of generality we write i and o to denote, respectively, 
the lists of input and output trajectories. 

Consider a composite function block FB (e.g., see Fig. 9 in Sec. 4). The requirements predicate of 
FB (denoted as FBJfEQ, e.g., Trip sealedin REQ) returns true if its outputs are related to inputs in the 
expected way (specified using tabular expressions) across all time ticks. The implementation predicate 
of FB (denoted as FBJMPL, e.g., Trip sealedin JMPL) is constructed by composing, using logical con¬ 
junction, the requirements predicates of its component FBs (e.g., TON, CONJU, etc.) as configured in its 
FBD implementation. All inter-connectives (e.g., wl, w2, etc.) in the FBD implementation arc hidden 
using an existential quantification. 

Proof of Consistency To ensure that the implementation is consistent or feasible, we prove that for each 
list of input trajectories, there exists at least one list of output trajectories such that FBJMPL is defined: 

h Vi • 3o • FBJMPL{i , o) (2) 

Proof of Correctness To ensure that the implementation is correct with respect to the intended require¬ 
ment, we prove that the observable inputs and outputs conform to those of the requirements: 

h Vi • Vo • FBJMPL(i, o ) => FBJREQ(i , o) (3) 

3 Formalizing IEC 61131-3 Timers with Tolerances 

We present the first contribution of this paper: incorporating the notion of timing tolerances H51 (i.e., the 
controller’s reaction to the environment is associated with a delay) into the formalization of the black¬ 
box, input-output requirements of IEC 61131-3 timers. Such formalization improves the accuracy of our 
previous work 1101 by making the resulting requirements models implementable. 
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In IEC 61131-3 there are three timer FBs: TON (On-delay), TOT (Off-delay), and TP (Pulse) timers. 
As case studies presented in this paper (Sec. 4 and Sec.5) only make use of the TON block, in this section 
we present its re-formalization only and report details of the other two timer blocks in fill . 
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Figure 4: TON timer declaration and definition in timing diagram [6] 


The TON block is commonly used as a component of safety-critical systems. For example, it can be 
used to determine if a sensor signal has gone out of its safety range for too long, as we will see in Sec. 4 
and Sec. 5. Fig. 4 shows, extracted from IEC 61131-3, the input-output declaration (on the LHS) and 
a timing diagram 3 (on the RHS) illustrating the expected behaviour of the TON block. The TON block 
is declared with two inputs (a boolean condition IN and a time period of length PT) and two outputs (a 
boolean value Q and a length ET of time period). Timer TON monitors the input condition IN and sets 
the output Q as true whenever IN remains enabled for longer than a time period of some input length PT. 
If the monitored input IN has been enabled for some time t < PT , then the timer sets the output ET (i.e., 
elapsed time) with value f; otherwise, it sets ET with value PT. 

The use of a timing diagram by IEC 61131-3 to describe the expected behaviour of the TON block 
(and the other two timers) is limited to an incomplete set of use cases. As a result, we attempted in HOI 
to use function tables to formalize the black-box, input-output requirements of the three timer blocks 
(on-delay, off-delay, and pulse timers) listed in IEC 61131-3. Fig. 5 shows our previous attempt of the 
requirements specification of the TON block, where t denotes the current clock tick, and a time stamp 
last.enabled is used to record the exact time (with no delay) that the input condition IN just becomes 
enabled. However, the requirements model in Fig. 5 is not implementable because it describes idealized 
behaviour: the timer (or the controller) reacts instantaneously to changes in the environment. 

As part of the contribution of this paper, we revise the function tables of all three timers in IEC 61131- 
3 by incorporating the notion of timing tolerances [15]. To achieve this, we use the pre-verified operator 
Timer J (Sec. 2) to redefine requirements of the three timers (e.g.. Fig. 6 for the TON timer). 

The essence of our first contribution presented in this section is that we incorporate the notion of 
timing tolerances, via the use of the pre-verified operator Timer J, into the requirements of IEC 61131 
timers so that they are implementable. This allows us to conduct case studies such as the one in Sec. 4 
on implementing and verifying subsystems using the IEC 61131-3 timers. 


3 The horizontal axis is labelled with time instants i £ 0..5 
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Figure 5: Tabular Requirements of Timer TON: Idealized Behaviour 



where d stands for duration, d = (IN) Timer J (PT, 5L, 5R) 
Figure 6: Tabular Requirements of Timer TON: Timing Tolerances Incorporated 


4 Case Study 1: the Trip Sealed-In Subsystem 


In this section we apply our approach (Sec. 2.6) to verify a candidate FBD implementation for the 
Trip Sealed-In subsystem. We identify an initialization error and suggest a fix. 

4.1 Input-Output Declaration and Informal Description The figure below declares the inputs 
and outputs of the Trip Sealed-In subsystem: 


BOOL 

{e_Trip, e_NotTrip} 
REAL 
BOOL 


Trip Sealed-In 


-1Any_parm_trip 
-1 Trip 

-|k_Sealindelay 
-|Man_reset_req 
+ - 


Trip_SealedIn 


-- BOOL 


Trip Sealed-In is a generic subsystem which monitors: 1) a set of sensor values; and 2) an alarm value 
produced by some other subsystem. It signals an alarm (denoted by the output TripJSealedln), which 
may be manipulated by other subsystems, when two conditions are met. First, any of the monitored 
sensor values goes out of its safety range (called a parameter trip and denoted by an input condition 
Any_parmJrip). Second, the monitored input alarm is signalled continuously for longer than some 
preset constant kJSealindelay 4 amount of time (denoted by an input value Trip of enumerated type 
{e_Trip,e_NotTrip}). Once the alarm Trip_SealedIn is activated, it is not deactivated until all monitored 
sensor values fall back within their safety ranges, and then a manual reset is requested (denoted as an 
input Man reset req). 

4.2 Tabular Requirements Specification with Timing Tolerances We use a function table 
(Fig. 7) to perform a complete and disjoint analysis on the input domains. To incorporate timing toler¬ 
ances into the requirements of Trip Sealed-In, we use the non-deterministic HeldJFor operator (Sec. 2) 
to specify a sustained window of duration [kJSealindelay — 8L. kJSealindelay + 8R\. 

4 The kj name prefix is reserved for system-wide constants. 
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Figure 7: Trip Sealed-In : (non-deterministic) Requirements of with Tolerances 


However, for the puipose of verification in PVS, we reformulate the non-deterministic behaviour of 
Fig. 7 in a recursive function 5 using the deterministic Held_ForJ operator to impose the constraint that 
only a single value (i.e., kJSealindelay — deltaJL where both are declared constants) is chosen from the 
duration and is used consistently for detecting sustained events. 

Below we define a recursive function TripSealedlnpf over all clock ticks: 


Trip_SealedIn_f(Any_parm_trip: pred[tick] , 

Trip : [tick->{e_Trip, e_NotTrip}], 

Man_reset_req: pred [tick])(t: tick) 

: RECURSIVE bool = 

IF init(t) THEN TRUE ELSE 
LET 

TRIPPED = LAMBDA (t: tick): Trip(t) = e_Trip, 

HELD = Held_For_I(TRIPPED,k_Sealindelay-delta_L,Sample)(t), 

PREV = Trip_SealedIn_f( 

Any_parm_trip,Trip,Man_reset_req)(pre(t)) 

IN TABLE 
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I 

% 

ENDTABLE ENDIF MEASURE rank(t) 
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NOT 

Man_reset_req(t) 
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Using Trip Sealed!n f, we have deterministic requirements (Fig. 8) for the Trip Sealed-In subsystem: 

Remark. Compared with Fig. 7, the use of the operator HeldJForl in Fig. 8 resolves the non¬ 
determinism by fixing the level of tolerance (i.e., as the alarm input Trip has been activated for or longer 
than kJSealindelay — SL, the Trip Sealed-In subsystem is guaranteed to detect it and act accordingly). 

4.3 Formalizing the FBD Implementation We propose a FBD implementation (Fig. 9) which 
should satisfy the requirements (Fig. 8). 

We use the IEC 61131 TON timer (see Sec. 3 for its formalization incorporated with tolerances) 
to implement the use of the Held-ForJ operator (subject to a correctness proof which we will discuss 
below). As the recursive function used to define the requirements depends on the value of itself (at the 
previous time tick), we specify a feedback loop (dashed line) in the implementation. 

5 For proving termination, its progress is measured using discrete time instants rank(t). 
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Trip_SealedIn_REQ(Any_parm_trip 

: pred [tick], 

Trip 

: [tick->{e_Trip, e_NotTrip}], 

Man_reset_req 

: pred [tick], 

TripSealedln 

: pred[tick]): bool 

= FORALL (t: tick): 


TripSealedln(t) = 


Trip_SealedIn_f(Any_parm_ 

trip, Trip, Man_reset_req)(t) 


Figure 8 : Trip Sealed-In: (deterministic) Requirements of with Tolerances in PVS 


Any_parm_trip 
(TRUE: Tripped, 
FALSE: Not Tripped) 

Trip 

(TRUE: Trip = e_NotTrip, 
False: Trip = e_Trip) 


k_Sealindelay 

Man_reset_req 


I I 



Figure 9: Trip Sealed-In implementation in FBD 


The use of the left-most NOT (negation) block in Fig. 9 has to do with the mismatch between types at 
the requirements level (i.e., {e Trip.e NotTrip}) and that at the FB implementation level (i.e., boolean): 
somehow the engineers interpret value e_Trip as FALSE and eJVotTrip as TRUE , so a conversion is 
necessary to make sure the Trip Sealed-In has a consistent interpretation. The requirements that the 
alarm output Trip JSealedin is deactivated (or reset) when there is no parameter trips, and when a manual 
reset is requested, is implemented using a standard block RS (reset dominant flip flop). 

To prove that the proposed FBD implementation of Trip Sealed-In (Fig. 9) is both feasible and con¬ 
forms to its requirements (Fig. 8 ), we follow our approach (Sec. 2.6) to formalize it by composing, using 
conjunction, the formalizing predicates 6 of all component blocks (all inter-connectors are hidden using 
an existential quantification.): 

Trip _sealedinJMPL(Any_parmJrip, Trip, Man_reset_req,T rip JSealedin) 

= 3 vv i. W 2 , wj , vvq, W 5 , W(y , et seal in • 

/ NOT(Trip,w 6 ) \ 

A TON(w(,,k_Sealindelay — 8L.w\.et seal in) 

A CONJ{Any_parmJrip,w 1 , W 2 ) 

A DISJ(w 2 , Trip Seale din, W 3 ) 

A NOT(Any _parm_trip ,w$) 

A CONJ(w 5 ,Man-reset-req,w<i ) 

\ A RS(w 4 ,w 3 , Trip Seale din) ) 


Predicates NOT (logical negation), CONJ (logical conjunction), DISJ (logical disjunction), TON (on-delay timer), and RS 
(reset dominant latch). 
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4.4 Proofs of Consistency and Correctness First, we prove that the FBD implementation (Fig. 9) 
is feasible by instantiating formula (2) in Sec. 2.6: 

F V Any_punn Jrip. Trip. Man_reset_req • 

3 TripJSealedln • Tripsea led in JMPL( 

Any _parm Jrip , AbstParmTripJimed(Trip), Man_reset_req , TripJSealedln) 

The abstraction function AbstParmTripAimed handles the mismatched types of input Trip at levels of 
requirements and implementation (e.g., eJNotTrip mapped to TRUE). We discharge the consistency 
proof using proper instantiations. 

Second, we prove that the FBD implementation is correct with respect to Fig. 8, considering timing 
tolerances, by instantiating formula (3) in Sec. 2.6: 

FV Any jp arm Jrip, Trip, Man _reset _req. TripJSealedln • 

Trip sealed in JM PL (A ny _pa nn Jrip. AbstParmTrip Jimed(Trip), Man-reset-req, TripJSealedln) 

=>- Tripsealedin_REQ(Any_parm_trip, Trip , Man_reset_req. TripJSealedln) 

As there is a feedback loop in the FBD implementation (Fig. 9), our strategy of discharging the cor¬ 
rectness theorem is by mathematical induction (using the time-induction proposition in Sec. 2) over tick 
values. Since the Timer J operator (Sec. 2) is used to formalize the requirements of the TON timer that 
contributes to the FBD implementation, its definition is expanded in both the base and inductive cases. 

However, when proving the base case (when t = 0), we found that the initial value of output Q1 of 
the RS-Sealin block and the initial value of the subsystem output TripJSealedln — these two values are 
directly connected in the initial FBD implementation (Fig. 9) — are inconsistent. According to the SRS 
(Software Requirements Specification), the value of TripJSealedln is initialized to TRUE , whereas that 
of Q1 is FALSE. We resolve this issue of inconsistency by suggesting a revised FBD implementation 
(Fig. 10) and prove that it is correct with respect to Fig. 8. In this revised implementation, we add an 
IEC 61131-3 selection block SELJSealin, acting as a multiplexer to discriminate the value of Q1 (at the 
initial tick and at the non-initial tick) that is output as TripJSealedln. 

Remark. We just illustrated that, by adopting our approach, we are able to justify the appropriateness 
of a candidate FBD implementation, and to fix it accordingly if necessary. 


Any_parm_trip 
(TRUE: Tripped, - 
FALSE: Not Tripped) 

Trip 

(TRUE: Trip = e_NotTrip,- 
False: Trip = e_Trip) 


k_Sealindelay- 
Man_reset_req- 


NOT 


w6 


TON_Sealln 

TON 

- IN Q 

- PT ET 


wl 


■et sealin 


t = 0 


ANDw2 or 


w3 


NOT w5 


AND 


w4 




SEL Sealin 

RS Sealin 



SEL 

RS 



G 

S Q1 

W/ 

INO Q1 




INI 

R1 





TRUE- 


Q1 —Trip_Sealedin 


Figure 10: Revised Trip Sealed-In implementation in FBD 


5 Case Study 2: the Pushbutton Subsystem 

In this section we apply our approach (Sec. 2.6) to verify a candidate FBD implementation for the 
Pushbutton subsystem. We identify a missing assumption of implementation and suggest a solution. 
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5.1 Input-Output Declaration and Informal Description The figure below declares the inputs 
and outputs of the Pushbutton subsystem. 

+ - + 

| Pushbutton | 


y_pb --|m 

REAL --|k_Debounce 

REAL --|k_Stuck 


f_Pushbutton 


y_pbdesign 


Pushbutton is a generic subsystem which monitors the status of a pushbutton (denoted by an input m e 
{e_Pressed,e_NotPressed}), which may be pressed to manually, e.g., enable or disable a sensor trip 7 8 . 
Its behaviour is denoted by an output f-Pushbutton £ {e pbNotDebounced.e pbDebounced.e pbStuck). 
Pushbutton determines if either: (a) the button is not pressed, or pressed but not for a sufficient period 
of time (denoted by some pre-set value kJDebounce % ) to register as a press; (b) the button is pressed 
long enough to quality as a press; or (c) the button is pressed for longer than some pre-set period of time 
(denoted by kStuck ) without bouncing back and thus is considered stuck. 

5.2 Tabular Requirements Specification with Timing Tolerances For the purpose of verifica¬ 
tion in PVS, we use the function table below 9 to perform a complete and disjoint analysis on the domain 
of the button status. To incorporate timing tolerances, similar to the requirements specification for the 
Trip Sealed-In subsystem (Fig. 8, p.74), we use the deterministic HeULForJ operator (Sec. 2), where 
values kJDebounce — 8L and kStuck — SL are chosen and used consistently for detecting the sustained 
events. 


Result 


Condition 

[.Pushbutton 

m = e NolPressed 

e pbNotDebounced 

(m = e .Pressed ) A —>debounced 

e .pbNotDebounced 

debounced A -i stuck 

egpbDebounced 

stuck 

ejpbStuck 


where debounced = (m = e Pressed) Held For I (k Debounce — 8L ) 


stuck = (m = e_Pressed) Held_For_I (kStuck — SL) 


5.3 Formalizing the FED Implementation We propose a FBD implementation which should 
satisfy the requirements: 


m 

(TRUE: e_Pressed, 
FALSE: e_NotPressed) 


k Debounce 


k Stuck 



pbNotDebounced 
(When TRUE, PB state is 
e_pbNotDebounced) 

pbDebounced 
(When TRUE, PB state is 
e_pbDebounced) 


pbStuck 

(When TRUE, PB state is 
e_pbStuck) 


7 A sensor trip occurs if the sensor signal in question goes above its set point. 

8 The k. name prefix is reserved for system-wide constants. 

y The PVS encoding of this table is not shown in this paper. 
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We use two IEC 61131 TON timers (see Sec. 3 for its formalization) to implement the predicates 
debounced and stuck in the above requirements table that involve the use of the Held For I operator. 
Since only the button status is monitored, there is no need to specify a feedback loop in the implemen¬ 
tation. To prove that this FBD implementation is consistent and correct, similar to what we do for that 
for the Trip Sealed-In subsystem (see Fig. 9, p.74), we formalize it by composing the formalizing pred¬ 
icates of all its component blocks using conjunction, and by hiding inter-connectors using an existential 
quantification. 

5.4 Proof Obligations: Consistency and Correctness The consistency and correctness theo¬ 
rems for the Pushbutton subsystem are stated in a similar manner as those for the Trip Sealed-In sub¬ 
system by properly instantiating, respectively, formulas 2 and 3 in Sec. 2.6. However, we had diffi¬ 
culties when first attempting to prove that the above requirements table for /_ Pushbutton possesses the 
disjointness property. To resolve this, we tried to simplify the requirements table by collapsing the 
first two rows into a single one with the input condition -> pressed A -i stuck. This is done based on 
the observations that both row 1 and row 2 map to the same output value eppbNotDebounced, and that 
m = e Pressed V m = e NotPressed = true. 

When proving that the revised requirements table is equivalent to the original one, we found a prob¬ 
lematic scenario where the value of output f-Pushbutton is produced inconsistently at the requirements 
and implementation levels: when the input condition m varies rapidly and generates a “spike”, whose 
duration is shorter than the timing resolution. To rule out the “spike” scenarios for input m, we added an 
assumption, at the FBD implementation level, using the predicate subtype FilteredTickPred (Sec. 2). 

Finally, the revised requirements table can be proved for its completeness, disjointness, consistency, 
and correctness by following a similar pattern of proofs as for the Trip Sealed-In subsystem. For prov¬ 
ing the correctness theorem, as there is not a feedback loop in the above FBD implementation, we do 
not need to discharge the correctness theorem using mathematical induction. Furthermore, as the TON 
components in the FBD implementation are formalized using the Timer J operator (Sec. 3), we need to 
reuse the theorem TimerGeneralJ with proper instantiations to show their equivalence to the Held For I 
expressions in the revised requirements table. 

6 Proof Structure 

In the industrial software control system that we consider for this paper, the Trip Sealed-In subsystem 
implemented using a feedback loop (Sec. 4) and the Pushbutton subsystem (Sec. 5) are representative 10 
of functionality in which FBD implementations make use of IEC 61131 timer blocks. Structures of their 
consistency and correctness proofs shall guide the proofs for many other subsystems of a similar nature. 

For illustration, we consider the correctness proof structure for the Trip Sealed-In subsystem. In 
principle, there are eight key steps to discharge the correctness theorem for a real-time subsystem imple¬ 
mented with a feedback loop (e.g., Trip Sealed-In). Except for the fourth step, where the time .induction 
theorem is used to handle the feedback loop, others are standard commands. 

1) Apply skosimp to eliminate the universal quantification over input and output variables, and then 
apply flatten to simplify theorem structure impl =0 req by moving impl to the antecedent and req to the 
consequent. 2) Apply multiple expand commands to unfold definitions of the requirements and imple¬ 
mentation predicates. 3) In the antecedent, apply skolem! to eliminate the existential quantification over 
inter-connectors. 4) To handle the recursive feedback loop, use the theorem time .induction on t £ tick. 

10 This judgement is based on the use of a generic timing function, the Held.For operator, in the tabular expressions that 
describe the required behaviour. 
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5) Apply a series of basic commands to complete the proof for the base case. 6) To prove the inductive 
case, first apply skolem! and then expand to unfold the recursive function that is used to define the 
requirements predicate (e.g., see Fig. 8, p.74). 7) Apply split and lift-if to generate sub-goals. 8) 
Repeatedly apply: expand commands to unfold definitions of the predicates for internal components, 
theorem TimerGeneralJ with proper instantiations to link between Ffeld_ForJ in the requirements and 
Timer J in the implementation, and basic commands to complete the proof for the inductive step. 


7 Related Work 

The focus of this paper is the practical verification of real-time behaviour against timing requirements 
with tolerances. Our approach to specifying and verifying FBs 1101 , compared with others on verifying 
PLC programs in contexts of model checking and theorem proving, is novel in three aspects: (1) extent 
of the case study; (2) practical application in the safety-critical industry; and (3) mature tool support of 
theorem proving. 

In our formal setting, proving that an FBD implementation is correct (with respect to its intended 
input-output timing requirements) is essentially proving that it is a valid refinement. Flowever, our pur¬ 
pose of verification is on the observable input-output behaviour, as opposed other properties such as 
boundedness, liveness, and robustness (e.g., [3, j_6, J_3_, 2J). Of more relevance is the use of timed au¬ 
tomata to model timing tolerances with ASAP (as soon as possible) semantics to verify the correctness 
of implementation [17], but with no suggestion for either tool support or its adoption in practice. 


8 Conclusion 

In this paper we report our application of a formal approach on using FBs (including timers) from 
IEC 61131-3 to verify two subsystems of an industrial software control system from the nuclear domain. 
We re-formalize all three IEC 61131-3 timers to incorporate the notion of tolerances. Specifically, we 
use the re-formalized IEC 61131 on-delay timer for the proposed FBD implementations, and prove that 
they are feasible and correct (i.e., satisfies the intended timing requirements). While attempting to verify 
the two subsystems, we find an issue of initialization failure, and an issue of missing implementation as¬ 
sumption. In both cases, we suggest possible solutions. We identify patterns of proof commands that are 
amenable to strategies that will facilitate the automated verification of the feasibility and correctness of 
other subsystems. As ongoing and future work, we first aim to verify subsystems with more sophisticated 
timing requirements, e.g., nested HeldfFor expressions. Second, we aim to prove safety properties from 
the composition of real-time subsystems. Third, we aim to automate the process of proofs that share a 
common structure. 
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